Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming

More Developers Are Using the Rust Programming Language, Survey Finds (rust-lang.org) 117

Posted by EditorDavid from the Rust-never-sleeps dept.
This month the official Rust blog announced: For the 6th year in a row, the Rust Project conducted a survey on the Rust programming language, with participation from project maintainers, contributors, and those generally interested in the future of Rust. This edition of the annual State of Rust Survey opened for submissions on December 5 and ran until December 22, 2022... [W]e had 9,433 total survey completions and an increased survey completion rate of 82% vs. 76% in 2021...

- More people are using Rust than ever before! Over 90% of survey respondents identified as Rust users, and of those using Rust, 47% do so on a daily basis — an increase of 4% from the previous year.

- 30% of Rust user respondents can write simple programs in Rust, 27% can write production-ready code, and 42% consider themselves productive using Rust. Of the former Rust users who completed the survey, 30% cited difficulty as the primary reason for giving up while nearly 47% cited factors outside of their control.

- The growing maturation of Rust can be seen through the increased number of different organizations utilizing the language in 2022. In fact, 29.7% of respondents stated that they use Rust for the majority of their coding work at their workplace, which is a 51.8% increase compared to the previous year.

- There are numerous reasons why we are seeing increased use of Rust in professional environments. Top reasons cited for the use of Rust include the perceived ability to write "bug-free software" (86%), Rust's performance characteristics (84%), and Rust's security and safety guarantees (69%). We were also pleased to find that 76% of respondents continue to use Rust simply because they found it fun and enjoyable. (Respondents could select more than one option here, so the numbers don't add up to 100%.)

- Of those respondents that used Rust at work, 72% reported that it helped their team achieve its goals (a 4% increase from the previous year) and 75% have plans to continue using it on their teams in the future.

- But like any language being applied in the workplace, Rust's learning curve is an important consideration; 39% of respondents using Rust in a professional capacity reported the process as "challenging" and 9% of respondents said that adopting Rust at work has "slowed down their team". However, 60% of productive users felt Rust was worth the cost of adoption overall...

- Of those respondents who shared their main worries for the future of Rust, 26% have concerns that the developers and maintainers behind Rust are not properly supported — a decrease of more than 30% from the previous year's findings. One area of focus in the future may be to see how the Project in conjunction with the Rust Foundation can continue to push that number towards 0%.

- While 38% have concerns about Rust "becoming too complex", only a small number of respondents were concerned about documentation, corporate oversight, or speed of evolution. 34% of respondents are not worried about the future of Rust at all.

This year's survey reflects a 21% decrease in fears about Rust's usage in the industry since the last survey.
This discussion has been archived. No new comments can be posted.

More Developers Are Using the Rust Programming Language, Survey Finds More

More Developers Are Using the Rust Programming Language, Survey Finds

Comments Filter:

  • People use Java too (Score:3, Interesting)

    by Anonymous Coward on Sunday August 27, 2023 @10:31PM (#63802502)

    This is just like Java all over again and in 25 years the situation will suck just as much.

    Fundamental issues can't be "fixed later."

    • Which specific fundamental issues?

      Rust is one of few languages that actually delivers everything it promised, and more. Java didn't even remotely do that. It's not a "better c" and it's certainly not "write once, run everywhere".

      • fuck Rust (Score:1)

        by Anonymous Coward
        It broke the Firefox port to OS/2 because there's no Rust compiler for OS/2. So many people think the world is little-endian, Linux or Windows (with BSD as an honorable mention if it's not too much effort), Intel or ARM.

      • Re: (Score:2)

        by lsllll ( 830002 )
        Not that I'm a fan of Java (I'm not) or that I'm even proficient in Java, but from my limited understanding, Java code that has been compiled into bytecode does run everywhere than can run the bytecode. Yes, implementations of Java will differ between Oracles and OpenJDK, but that's understandable.

        Can you expand on why it doesn't run everywhere?

        • Re: People use Java too (Score:4, Informative)

          by ShanghaiBill ( 739463 ) on Monday August 28, 2023 @12:32AM (#63802596)

          Can you expand on why it doesn't run everywhere?

          The claim was that you write and debug once on one platform, and then you can deploy the bytecode and it will run with the same behavior everywhere.

          That is not true. There are plenty of quirks on different OSes, and the behavior in the browser is even more different.

          So you end up running tests and debugging for each platform, exactly what Java promised you could avoid.

          • Re: (Score:3)

            by flink ( 18449 )

            It has been close to 2 decades since I've run into a JVM-level issue that has caused any Java code I wrote to be non-portable. Of course to the extent that you interact with the OS and environment outside the JVM, you have to take care to do so in a portable fashion. Java can't save you from being lazy or stupid, but for headless backend server stuff, you really have to be trying to shoot yourslef in the foot (e.g., using undocumented platform packages, hard coding "\" into paths instead of using file sys

            • Re: (Score:2)

              by lsllll ( 830002 )
              And TBH this is what my experience has been. When I run back-end stuff on servers, the .jar files work no matter what platform I throw them at.

              • not my employers experience at all, 22 years of codebase, millions of lines, and minor point releases of oracle java break things. we wont even talk of openjdk or IBM's websphere java

                • Never use Oracle Java unless you must.

                  Never use Oracle anything unless you must.

                  Consider that they looove suing people, even their own customers, and that unless your market cap is similar to Oracle's, that lawsuit, or even the negotiated settlement you have to pay to avoid it, will likely drive you to bankruptcy.

                • Here's one for you: Back in 2017, before I had any intention whatsoever of doing any kind of software development and my programming knowledge at the time was limited to just very basic powershell stuff, I was bitten by a java compatibility problem. But this is even worse than differences between OSes, because it was literally on the EXACT SAME OS. Basically I was admin of a pair of servers that did some network stuff. One day, one of the servers just stops talking to an upstream vendor-owned server. Well i

            • Java breaks code with minor point releases now. IBM, Oracle or Openjdk also differ in bad ways. if you have millions of lines of java you see plenty of issues.

            • Actually the problems I've had with java have been exclusively on the back end, mainly because the JRE is already annoying enough to help end users troubleshoot that I won't even write client code in it, or any code at all if I can help it. If I have to write client code, and it has to be in a language like this for whatever oddball reason, C# it is.

              And I'm not even talking about differences between OSs, rather just just the JRE itself even on THE EXACT SAME OS. Point releases have broken my own code more t

          • Re: People use Java too (Score:4, Insightful)

            by Malc ( 1751 ) on Monday August 28, 2023 @03:03AM (#63802684)

            Wasnâ(TM)t Java in browsers phased out years ago?

          • That is not true. There are plenty of quirks on different OSes, and the behavior in the browser is even more different.
            25 years ago perhaps. We have 2023 now ...

          • I've rarely run into platform-specific issues in any language I've used much (which does include Java back in the day, and more recently Python, Javascript and C# on .NET Core).

            Except for self-inflicted stupidity, like hardcoding path separators or trying to write to Windows-specific folder and file names or ignoring differences in case sensitivity between filesystems.

            I'm not quite sure how it's the language's fault if a developer does stoopid stuff like that, even though on occasion I've managed to do so m

            • I'm not a Java developer, but I've had to deploy Java stuff a whole lot over the decades. And none of it is ever cross platform. It's always windows specific, or some really specific version of RedHat. It's easy to say "it's the developer's fault, not the language" but at some point you have to ask yourself if the language just made cross platform harder than it had to be causing people who would otherwise have tried to be good to just say "fuck it, there's a platform native path going in here so I can go h

              • I don't see how a language can be blamed for crappy development practices. Even though (a) I do have issues with Java and (b) I know it seems easier to hardcode stuff, if you can get away with that, instead of doing it right.

                I promise that although Python and C# on .NET Core are fairly competently cross-platform if done correctly, things often aren't done correctly, and the usual results would be very much like what you described.

                The rules in all these cases are pretty simple, and include (though I'm sure

        • Yes, implementations of Java will differ between Oracles and OpenJDK, but that's understandable
          It is the same, it is just rebranded.

        • "Can you expand on why it doesn't run everywhere?"

          I'm a long way from being any kind of Java expert but what springs to my mind is the program calls system routines that won't be there on all systems. Since this will likely include I/O routines, this has the potential to be pretty wide-ranging.

      • Re: People use Java too (Score:4, Funny)

        by organgtool ( 966989 ) on Sunday August 27, 2023 @11:42PM (#63802570)

        Rust is one of few languages that actually delivers everything it promised, and more

        While I prefer Rust to C/C++ so far, I find this statement to be a bit hyperbolic. I've had a number of issues getting Rust to perform things that are trivial in many other languages.

        Java didn't even remotely do that. It's not a "better c" and it's certainly not "write once, run everywhere".

        That's certainly the case for desktop applications, but it's superior to C for server-based systems. As far as I can tell, C/C++ still don't have an answer for Java Beans almost 30 years after they were introduced. If you're developing a highly concurrent system, Beans perform a ton of heavy lifting when it comes to creating, destroying, and dispatching threads, which allows the developer to focus on the primary objectives of the system instead of writing lots of thread-management code. And I've never had a single server-based Java application present problems based on the environment in which it executes. As a matter of fact, there are many projects today where different developers of a given project run Linux, Mac, and Windows, and the project runs comparably in all of those environments without requiring even a single change in configuration.

        • While I prefer Rust to C/C++ so far, I find this statement to be a bit hyperbolic. I've had a number of issues getting Rust to perform things that are trivial in many other languages.

          First, what does this have to do with anything rust has promised? Nobody ever said you'd be able to directly port your code using the same logic. In fact it's pretty much expected that you won't be able to because of rust's rather unique semantics.

          Second, this will depend heavily upon how you're used to structuring your code. C/C++ will let you do things that are fundamentally unsound, and rust won't. That means if you're used to, for example, mutating referenced memory while you have another reference to i

          • Nobody ever said you'd be able to directly port your code using the same logic. In fact it's pretty much expected that you won't be able to because of rust's rather unique semantics.

            I'm not talking about porting code. I'm talking about using simple design patterns, such as a Singleton (yes, I know they're considered evil now because every project had that one person that tried to make everything a Singleton, but occasionally they're still the right tool for the job). The only way I've found to do that is

          • Nobody ever said you'd be able to directly port your code using the same logic. In fact it's pretty much expected that you won't be able to because of rust's rather unique semantics.

            Don't you love it when you can implement the same idea the same way in 20 different languages, but Rust forces you to completely rethink it for just one weirdo language? I think it's awesome when you can spend double the time on design because of one language. I'm sure everyone loves the wasted time.

            • Don't you love it when you can implement the same idea the same way in 20 different languages, but Rust forces you to completely rethink it for just one weirdo language? I think it's awesome when you can spend double the time on design because of one language. I'm sure everyone loves the wasted time.

              Well let's put it this way: Just because you can implement something a particular way, doesn't mean you should do it the same way in every language.

              Take for example how, because you started with microsoft basic, you don't believe in functions so you still use goto in every language. But just because you can do that in your new preferred languages doesn't mean you should. And of course, there is no such thing as goto in rust, so you're kind of dead in the water there.

        • Re: (Score:2)

          by DrXym ( 126579 )

          I've had a number of issues getting Rust to perform things that are trivial in many other languages.

          Rust is a low level language so I can see it poses issues for people coming from high level languages. The same is true moving from Java to C++ though and you're in for a world of hurt.

          But even from C/C++ it will cause some frustration because the compiler is way more strict and the language is different enough that it can be confusing. There is no NULL, there is no classes or inheritance, and the rules for borrowing & mutability are different enough to cause a lot of issues. But when you overcome the i

        • As far as I can tell, C/C++ still don't have an answer for Java Beans

          Plenty of libraries to choose from. You can't solve everything in the language. That's why libraries exist.

        • I've had a number of issues getting Rust to perform things that are trivial in many other languages

          From what I've been told, that's by design, and Rust requires a mindset very different than most other languages.

          It forces you to think through concepts like ownership, borrowing, and lifetimes, which you should be doing in any low-level language anyway, but Rust makes this quite necessary, since if you goof any of this up in any way that it can detect, your code simply won't compile.

          While I've yet to le

      • Re: (Score:3)

        by Jeremi ( 14640 )

        Rust is one of few languages that actually delivers everything it promised, and more

        In this evaluation, "what it promised" is doing a lot of work.

        I'd say Brainf*ck [wikipedia.org] delivers everything it promised and more also, but of course what it promised is indicated in its name, so that might not be a good thing.

      • Certainly not true. Its main feature, the borrow checker, is arguably a failure: most code simply bypasses it by using reference counting.

        It managed to get somewhat popular due to completely different reasons. Cargo for example appears to be one of them.

        • From the little bit I understand, Rc is a kludgy hack that defeats much of the purpose of Rust. You may be tempted to depend on it as a beginner, but from everything I've read, you don't want to use it in production until you know the language well enough to be certain that no safer and more productive solution exists.

          If you want reference-counting garbage management, probably better to use a language in which that is built in.

          Use Rust when/if you decide you want to write code that's more or less provably

        • Certainly not true. Its main feature, the borrow checker, is arguably a failure: most code simply bypasses it by using reference counting.

          That's definitely not true, I've been over a lot of rust code and I've only ever seen it used where it makes sense to do so. And it's super easy to avoid using it, just think about where your data lives and the rest of the dominos will fall where they should.

          On the contrary, some other languages are either in the process of implementing or considering implementing a borrow checker, among them D and swift. This wouldn't be happening if it was a failure.

      • Re: People use Java too (Score:4, Insightful)

        by Entrope ( 68843 ) on Monday August 28, 2023 @06:00AM (#63802790) Homepage

        Taking nine months to publish survey results is an issue, although not fundamental.

        A year-over-year decrease in number of survey responses suggests deep-seated problems. That is confirmed by the 30% of former Rust users in this survey who said they gave up on the language because it is too hard.

        Only 27% of survey respondents claimed to be able to write a simple program in Rust -- but 90% of them claimed to be able to write production-ready code, and 38% of survey respondents feel productive despite being unable to write simple programs. If that's representative of the overall user base, Rust is in trouble because its users have delusions of competence.

        Fundamentally, this kind of survey is in the vein of "we investigated ourselves, and found we are awesome!" Contrast with Go's developer survey [go.dev], which focuses mostly on how Go developers use the language, what challenges they face, and where they want to see improvements in Go or development tools.

      • Java promised to be a high-level, relatively memory-safe, "write-once, run anywhere" (if done correctly) language.

        IMO, it did that. It fell short with regard to applets (which were a poor fit, security-wise, for the rest of Java). But mostly succeeded otherwise.

        But then Oracle. :(

    • Re:People use Java too (Score:5, Insightful)

      by sosume ( 680416 ) on Monday August 28, 2023 @01:02AM (#63802628) Journal

      If 90% of the respondents use Rust, the group probably isn't representative for the whole community. What a crap article.

  • 90% of respondents??? (Score:5, Insightful)

    by Gibgezr ( 2025238 ) on Sunday August 27, 2023 @10:37PM (#63802510)

    A survey of Rust devs found most of them used Rust. Surprise!

    • You mean the Rustocalypse?

    • Re: the perceived ability to write "bug-free softw (Score:4, Informative)

      by ShanghaiBill ( 739463 ) on Monday August 28, 2023 @12:50AM (#63802612)

      Nobody claims Rust programs are bug-free.

      But Rust does (mostly) avoid two major categories of bugs: Memory management and thread synchronization.

      Many common anti-patterns that cause these bugs won't even compile on Rust.

      Use after free()? Compiler error.
      Null pointer dereference? Compiler error.
      Two threads accessing the same data without locks? Compiler error.

      Personally, I struggle with Rust bcoz I tend to be a cowboy coder: Churn out code, get it working, and then go back and clean it up. That's difficult in Rust. I'm forced to do it right the first time, which slows me down and discourages exploratory coding. So I mostly stick to C++, but I can see the advantages of Rust for team projects.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Browse through the CVE databases for Rust software. I'd say it's no more secure than any other software. In fact from the issue reports it seems less secure than the notoriously insecure Java.

      • That's not true at all.

        First, Rust fearless concurrency is widely recognized for being a bad concurrency models with poor guarantees. It doesn't in any way remove synchronization bugs.

        Second, the borrow checker, even if you consider it to be a success (which it isn't) only prevents a small subset of bugs that only amateurs struggle with. It doesn't magically remove all of the more serious bugs in your program.

        • First, Rust fearless concurrency is widely recognized for being a bad concurrency models with poor guarantees. It doesn't in any way remove synchronization bugs.

          Link?

      • Move em on, head em up Head em up, move em on Move em on, head em up Rawhide Cut em out, ride em in, Ride em in, let em out, Cut em out, ride em in Rawhide!
  • It looks like Captain Obvious is wearing his underpants outside his suit again.

  • While 38% have concerns about Rust "becoming too complex"

    Welcome to the history of programming languages! All languages eventually become too complex.

    What are you going to do? Migrate to yet another language that is simple because it isn't used widely, or hasn't developed enough cruft because it hasn't been used long enough for backwards compatibility to matter?

    • Actually that's not quite true. There are languages which do a good job of not becoming too complex. Examples are languages like Forth or Lisp, languages that deliberately started off as simple as elegant. Both languages still see some important use.

      The problem is that many people think a language should have lots of features. If you are a young programmer you think that most features are shiny and desirable. If you get out of that phase you'll notice that many if not most language features are terrible hac

      • Lisp definitely became too complex. So complex it gave rise to MacLisp, Scheme, Common Lisp, Racket, Clojure, because it wasn't capable of keeping a lid on complexity. I keep trying to learn Common Lisp, but get put off by all the different kinds of "let". It makes C++ initialization look comparatively consistent.

        Macros create DSLs that no one else can decipher. The different kinds of quoting and un-quoting in macros makes things hard to follow.

        • I keep trying to learn Common Lisp, but get put off by all the different kinds of "let". It makes C++ initialization look comparatively consistent.

          That's quite ridiculous though. The "different kinds of LET" have very cleanly defined purposes, with them doing actually different things. C++ initializations do the same thing in eighteen slightly different ways..."for reasons". There's no reason for the latter except for historical baggage, whereas it's very clear what the LETs are for. At best you might claim that METABANG-BIND should have been the default in the language, but guess what...you can just use it in all your code and forget about the rest.

          • The "different kinds of LET" have very cleanly defined purposes

            whereas it's very clear what the LETs are for.

            So? I can define a class of functions for any thing that do very similar things, but with very cleanly defined purposes of each. I can define a whole series of "add 1toX", "add2toX", etc etc, and they'll all have cleanly defined purposes. But the question is: why? Why do you need so much in the first place?

            Also the claim that "Lisp became too complex" is hilarious. Try doing the same amount of functionality that Lisp offers you in something like C++, for example. Multimethods?

            Considering that most languages have gotten by without them means they're not necessary - hence became too complex.

            However, C++ template specializations work like multimethods at compile-time. And comp

            • So? I can define a class of functions for any thing that do very similar things, but with very cleanly defined purposes of each. I can define a whole series of "add 1toX", "add2toX", etc etc, and they'll all have cleanly defined purposes. But the question is: why? Why do you need so much in the first place?

              Except there's *much less* redundancy in Lisp's binding forms than there is in C++'s intializations, so one ought to raise that argument first and foremost against C++. If you don't complain even more loudly about C++'s initializations you don't have any right to complain about CL's binding forms.

              Considering that most languages have gotten by without them means they're not necessary - hence became too complex.

              Assembly languages have gotten by without local variables, but that doesn't make local variables undesirable or languages with local variables "too complex".

              However, C++ template specializations work like multimethods at compile-time. And compile-time is where I've needed that functionality more than at runtime. I haven't needed multimethods for runtime use. Simple virtual functions handle 99% of all cases.

              See, the funny thing is, the "too complex" Common Lisp al

    • All languages eventually become too complex.

      Have you seen the last iteration of Oberon?

      • Re: (Score:2)

        by andy55 ( 743992 )

        All languages eventually become too complex.

        Have you seen the last iteration of Oberon?

        How about this little language called Go. It's only used by a small company and crafted by amateurs and occasionally used for high performance computing, but it's worth checking out. The lang spec is still tiny with a stdlib that does all the things.

  • It's easy to focus on the memory safety features, which require care even to approximate with C++ code.

    There are a lot of treats beyond the learning-curve barrier, like composable iterators. For people motivated by making mistakes impossible, something which experience has led me to want, the Result data type is a treat. It's like a std::variant which can hold either an expected result or an error code, but the brilliant part is that AFAICT there is no way to write code that compiles that retrieves the resu

    • Re: I've been learning it for fun (Score:4, Insightful)

      by cyber-vandal ( 148830 ) on Monday August 28, 2023 @06:17AM (#63802820) Homepage

      You need to remember that unlike your senior dev colleague and you and I, the people commenting here are infallible and omniscient so a language that detects some mistakes at compile time is unnecessary.

      • I wouldn't say I'm omniscient. Not even particularly perceptive. Lord knows I can stare at a code block with an error and see nothing for an hour.

        What I can tell you is that I have no patience, zero, none, nada, for languages where it just sticks its hands on its hips and refuses to let you pass until you tick all its boilerplate boxes. This is (one of many reasons) why I gave up on Android development. I wasn't doing it professionally, it was a thing to do for fun, and it wasn't fun. I was trying to figure

    • For people motivated by making mistakes impossible, something which experience has led me to want, the Result data type is a treat. It's like a std::variant which can hold either an expected result or an error code, but the brilliant part is that AFAICT there is no way to write code that compiles that retrieves the result without having done some implicit or explicit error check.

      FWIW, C++ programmers have been building result types like that for many years (here's one example [android.com], in my code. It's from 2021, so it doesn't pre-date Rust, but if I dug a bit I could find some that do). They're not quite as good, since the failure to check has to be diagnosed with a run-time assertion, whereas Rust can do it at compile time (at least, if someone has found a metaprogramming technique that accomplishes compile-time detection in C++, I haven't seen it).

      But this is the case with almost every

  • Rust is basically the quasi-official successor to the "C" group of system languages. Even the hardcore C-camp acknowledges the benefits of this long overdue update of a fundamental systems language. By now even Linus and the Kernel-team allow for kernel-work to be done in Rust, and Linus is a "C-Nazi"/C-fanatic if there ever was one. It's obvious that the influence of Rust will continue to grown, it's what the world has been waiting for.

    I could even imagine that sometime in the (near) future, large C codeba

    • C is on the way out.

      Not for firmware.

      • Why would firmware be a special case?

        Firmware doesn't run C. It runs binary compiled code, and, if Rust can produce equally good binaries, then why not use Rust to produce them?

    • zero lines of Rust are running in hundreds of Linux servers i admin, start crowing when Rust proves itself by doing a little bit of work. It's an experiment with no results yet.

    • I don't see a fully automated migration anytime soon, because frankly a lot of what people try to do in C and C++ (typically when using the C-like subset of C++) does not work on Rust by design.

      I'm not convinced yet that C++, much less C, is going away anytime real soon, even for new code and even in the timeframe of the low-single-digit number of decades, but I do think it's pretty safe to say that anyone needing to write new low-level code should strongly consider learning and using Rust instead. I certa

    • For anyone wanting to do system-level coding today I would flat-out recommend starting with Rust right away and avoiding C in the future. By and large AFAICT C is on the way out. Not today, not in 10 years (potential major pushes in AI coding aside), but it's run it's course and there are very solid reasons to decomission C in favour of Rust to avoid the pitfalls of C that came about at a time when transistors and memory was very rare and highly valuable and people _had_ to cut corners to get any meaningful work done.

      C isn't going anywhere anytime soon and Rust will probably have been long since replaced with something far better by the time it does. More than likely grounded AI in the next few years brings formal programming to the masses. All Rust really does is enforce rigid constraints. A model checker can do the same thing in C or any language dynamically adjusting constraints to meet specific requirements as well as continuous innovation enabling rigidity to be dynamically elided as systems improve.

      Just picked

  • People never learn (Score:2, Insightful)

    by gweihir ( 88907 )

    Always falling for the grossly inflated claims of the next hype.

  • Undefined Behavior (Score:4, Funny)

    by cygnusvis ( 6168614 ) on Monday August 28, 2023 @04:27AM (#63802740)
    Since there is no defined spec of the rust language, all rust programs are undefined behavior.
  • I don't want to have to identify to use Rust.
  • The Halyna Hutchins function just doesnt do what it used to do anymore. Most of the applications are scattered and the dev team is never gonna get the band back together. Too soon??

Slashdot Top Deals

Real Programmers think better when playing Adventure or Rogue.

Close